Proaktyvus konvejeris: „JavaScript“ našumo automatizavimas pasaulinei auditorijai

Skaitmeninėje ekonomikoje greitis yra universali kalba. Vartotojas Tokijuje, Londone ar San Paule tikisi to paties: greitos, sklandžios skaitmeninės patirties. Kai interneto programa stringa, užšąla ar kraunasi kelias sekundes, tai ne tik nepatogumas; tai šio lūkesčio sulaužymas. Tai tylus vartotojų įsitraukimo, konversijų rodiklių ir prekės ženklo reputacijos žudikas. Daugelį metų našumo analizė buvo reaktyvi disciplina – karštligiškas gilinimasis į „Chrome DevTools“, kai vartotojai jau pradėjo skųstis. Šis požiūris nebėra tvarus nuolatinio diegimo ir pasaulinės vartotojų bazės pasaulyje.

Sveiki atvykę į proaktyvų konvejerį. Tai paradigmos pokytis nuo rankinių, ad-hoc našumo patikrų prie sistemingo, automatizuoto ir nuolatinio stebėjimo bei vykdymo proceso. Tai apie našumo įtraukimą kaip pagrindinį jūsų kūrimo ciklo principą, lygiai taip pat kaip vienetų testavimą ar saugumo skenavimą. Automatizuodami „JavaScript“ našumo profiliavimą, galite pagauti regresijas dar prieš joms pasiekiant produkcinę aplinką, priimti duomenimis pagrįstus optimizavimo sprendimus ir užtikrinti, kad kiekvienas vartotojas, nepriklausomai nuo jo buvimo vietos ar įrenginio, gautų geriausią įmanomą patirtį.

Šis išsamus vadovas paaiškins jums, kodėl, ką ir kaip sukurti savo nuolatinio našumo stebėjimo konvejerį. Išnagrinėsime įrankius, apibrėšime svarbiausius rodiklius ir pateiksime praktinių pavyzdžių, kaip integruoti šias patikras tiesiogiai į jūsų CI/CD darbo eigą.

Nuo rankinio profiliavimo iki automatizuotų įžvalgų: būtina evoliucija

Dauguma front-end programuotojų yra susipažinę su „Performance“ ir „Lighthouse“ skirtukais savo naršyklės programuotojo įrankiuose. Tai neįtikėtinai galingi instrumentai problemoms konkrečiame puslapyje diagnozuoti. Tačiau pasikliauti vien jais yra tarsi bandyti užtikrinti dangoraižio konstrukcijos vientisumą tikrinant tik vieną atraminę siją kartą per metus.

Rankinio profiliavimo apribojimai

• Reaktyvu, o ne proaktyvu: Rankinės patikros paprastai atliekamos, kai problema jau nustatyta. Jūs gesinate gaisrą, o ne jo išvengiate. Kol programuotojas atidaro „DevTools“ ištirti sulėtėjimą, jūsų vartotojai jau pajuto skausmą.
• Nenuoseklu: Rezultatai, kuriuos gaunate galingame programuotojo kompiuteryje, prijungtame prie greito biuro tinklo, labai skiriasi nuo to, ką patiria vartotojas su vidutinės klasės mobiliuoju įrenginiu regione su prastu ryšiu. Rankiniams testams trūksta kontroliuojamos, pakartojamos aplinkos.
• Užima daug laiko ir nėra mastelio keitimo galimybės: Išsamus našumo profiliavimas reikalauja daug laiko ir patirties. Kai programa auga sudėtingumu ir komandos dydžiu, programuotojams tampa neįmanoma rankiniu būdu patikrinti kiekvieno „commit“ dėl našumo regresijų.
• Sukuriami žinių silosai: Dažnai tik keli „našumo čempionai“ komandoje turi gilių žinių, reikalingų interpretuoti sudėtingas liepsnos diagramas ir atsekimo failus, taip sukuriant kliūtį optimizavimo pastangoms.

Argumentai už automatizavimą ir nuolatinį stebėjimą

Našumo profiliavimo automatizavimas paverčia jį iš retkarčiais atliekamo audito į nuolatinį grįžtamojo ryšio ciklą. Šis požiūris, CI/CD kontekste dažnai vadinamas „Sintetiniu stebėjimu“, siūlo didelių pranašumų.

• Anksti aptikite regresijas: Vykdydami našumo testus su kiekvienu „commit“ ar „pull request“, galite nedelsiant nustatyti tikslų pakeitimą, kuris sukėlė sulėtėjimą. Šis „poslinkio į kairę“ (shift left) požiūris daro problemų sprendimą eksponentiškai pigesnį ir greitesnį.
• Nustatykite našumo bazinę liniją: Automatizavimas leidžia jums sukurti istorinį jūsų programos našumo įrašą. Šie tendencijų duomenys yra neįkainojami norint suprasti ilgalaikį kūrimo poveikį ir priimti pagrįstus sprendimus dėl techninės skolos.
• Įgyvendinkite našumo biudžetus: Automatizavimas leidžia apibrėžti ir įgyvendinti „našumo biudžetą“ – ribinių verčių rinkinį pagrindiniams rodikliams, kuriuos „build“ turi atitikti, kad būtų sėkmingas. Jei pakeitimas sulėtina didžiausio turinio elemento atvaizdavimą (LCP) 20%, „build“ gali būti automatiškai atmestas, taip užkertant kelią regresijos įdiegimui.
• Demokratizuokite našumą: Kai grįžtamasis ryšys apie našumą pateikiamas automatiškai programuotojo esamoje darbo eigoje (pvz., komentaras prie „pull request“), tai įgalina kiekvieną inžinierių prisiimti atsakomybę už našumą. Tai nebėra vien specialisto atsakomybė.

Pagrindinės nuolatinio našumo stebėjimo sąvokos

Prieš pradedant nagrinėti įrankius, būtina suprasti pagrindines sąvokas, kurios sudaro bet kokios sėkmingos našumo stebėjimo strategijos pagrindą.

Pagrindiniai našumo rodikliai, kuriuos reikia stebėti („Ką“)

Negalite pagerinti to, ko nematuojate. Nors yra dešimtys galimų rodiklių, efektyviausia strategija yra sutelkti dėmesį į kelis, orientuotus į vartotoją. „Google“ pagrindiniai interneto rodikliai (Core Web Vitals) yra puikus atspirties taškas, nes jie sukurti matuoti realią vartotojo patirtį.

• Didžiausio turinio elemento atvaizdavimas (LCP): Matuoja įkėlimo našumą. Tai žymi tašką puslapio įkėlimo laiko juostoje, kai pagrindinis turinys tikėtinai buvo įkeltas. Geras LCP yra 2,5 sekundės ar mažiau.
• Sąveika iki kito atvaizdavimo (INP): Matuoja interaktyvumą. INP vertina bendrą puslapio reakciją į vartotojo sąveikas. Jis stebi visų paspaudimų, prisilietimų ir klaviatūros sąveikų delsą. Geras INP yra mažesnis nei 200 milisekundžių. (INP pakeitė pirmojo įvesties delsą (FID) kaip pagrindinį interneto rodiklį 2024 m. kovo mėn.).
• Kaupiamasis maketo poslinkis (CLS): Matuoja vizualinį stabilumą. Jis kiekybiškai įvertina, kiek netikėto maketo poslinkio patiria vartotojai. Geras CLS balas yra 0,1 ar mažiau.

Be pagrindinių interneto rodiklių, kiti svarbūs rodikliai yra šie:

• Laikas iki pirmojo baito (TTFB): Matuoja serverio atsako laiką. Tai pagrindinis rodiklis, nes lėtas TTFB neigiamai paveiks visus vėlesnius rodiklius.
• Pirmojo turinio elemento atvaizdavimas (FCP): Žymi laiką, kada atvaizduojamas pirmasis DOM turinio gabalas. Tai suteikia pirmąjį grįžtamąjį ryšį vartotojui, kad puslapis iš tikrųjų kraunasi.
• Bendras blokavimo laikas (TBT): Matuoja bendrą laiką tarp FCP ir interaktyvumo laiko (TTI), per kurį pagrindinė gija buvo blokuota pakankamai ilgai, kad būtų išvengta įvesties reakcijos. Tai puikus laboratorinis rodiklis, gerai koreliuojantis su INP.

Našumo biudžeto nustatymas („Kodėl“)

Našumo biudžetas yra aiškus apribojimų rinkinys, su kuriuo jūsų komanda sutinka dirbti. Tai ne tik tikslas; tai griežta riba. Biudžetas paverčia našumą iš neaiškaus „padarykime greitai“ tikslo į konkretų, išmatuojamą reikalavimą jūsų programai.

Paprastas našumo biudžetas gali atrodyti taip:

• LCP turi būti mažesnis nei 2,5 sekundės.
• TBT turi būti mažesnis nei 200 milisekundžių.
• Bendras „JavaScript“ paketo dydis neturi viršyti 250 KB (gzipped).
• „Lighthouse“ našumo balas turi būti 90 ar didesnis.

Apibrėžus šias ribas, jūsų automatizuotas konvejeris turi aiškų sėkmės/nesėkmės kriterijų. Jei dėl „pull request“ „Lighthouse“ balas nukrenta iki 85, CI patikra nepavyksta, ir programuotojas nedelsiant informuojamas – prieš kodas yra sujungiamas.

Našumo stebėjimo konvejeris („Kaip“)

Tipiškas automatizuotas našumo konvejeris veikia pagal šiuos žingsnius:

1. Paleidiklis: Programuotojas pateikia naują kodą į versijų kontrolės sistemą (pvz., „Git“).
2. Kompiliavimas („Build“): CI/CD serveris (pvz., „GitHub Actions“, „Jenkins“, „GitLab CI“) paima kodą ir paleidžia programos kompiliavimo procesą.
3. Diegimas ir testavimas: Programa yra įdiegiama į laikiną „staging“ arba peržiūros aplinką. Tada automatizuotas įrankis paleidžia našumo testų rinkinį šioje aplinkoje.
4. Analizė ir patvirtinimas: Įrankis surenka našumo rodiklius ir palygina juos su iš anksto nustatytu našumo biudžetu.
5. Ataskaita ir veiksmas: Jei biudžetas atitinka reikalavimus, patikra sėkminga. Jei ne, „build“ atmetamas, o komandai siunčiamas įspėjimas su išsamia ataskaita, paaiškinančia regresiją.

Šiuolaikinis įrankių rinkinys automatizuotam „JavaScript“ profiliavimui

Keletas puikių atvirojo kodo įrankių sudaro šiuolaikinio našumo automatizavimo pagrindą. Išnagrinėkime žinomiausius iš jų.

Naršyklės automatizavimas su „Playwright“ ir „Puppeteer“

„Playwright“ (iš „Microsoft“) ir „Puppeteer“ (iš „Google“) yra „Node.js“ bibliotekos, kurios suteikia aukšto lygio API, skirtą valdyti „headless“ „Chrome“, „Firefox“ ir „WebKit“ naršykles. Nors jos dažnai naudojamos „end-to-end“ testavimui, jos taip pat yra fenomenalios našumo profiliavimui.

Galite jas naudoti sudėtingoms vartotojo sąveikoms scenarizuoti ir rinkti išsamius našumo atsekimo duomenis, kuriuos galima analizuoti „DevTools“. Tai puikiai tinka matuoti konkrečios vartotojo kelionės našumą, o ne tik pradinį puslapio įkėlimą.

Štai paprastas pavyzdys, naudojant „Playwright“, norint sugeneruoti našumo atsekimo failą:

Pavyzdys: atsekimo failo generavimas su „Playwright“

• const { chromium } = require('playwright');
• (async () => {
• const browser = await chromium.launch({ headless: true });
• const page = await browser.newPage();
• // Pradėti atsekimą, išsaugant į failą.
• await page.tracing.start({ path: 'performance-trace.json', screenshots: true });
• await page.goto('https://your-app.com/dashboard');
• // Sąveikauti su puslapiu, norint profiliuoti konkretų veiksmą
• await page.click('button#load-data-button');
• await page.waitForSelector('.data-grid-loaded'); // Palaukti rezultato
• // Sustabdyti atsekimą
• await page.tracing.stop();
• await browser.close();
• console.log('Našumo atsekimo failas išsaugotas į performance-trace.json');
• })();

Tada galite įkelti `performance-trace.json` failą į „Chrome DevTools“ našumo skydelį, kad gautumėte išsamią, kadras po kadro analizę, kas įvyko tos vartotojo sąveikos metu. Nors tai yra galingas diagnostikos įrankis, mums reikia dar vieno sluoksnio automatizuotam patvirtinimui: „Lighthouse“.

„Google Lighthouse“ panaudojimas išsamiems auditams

„Lighthouse“ yra pramonės standartas, atvirojo kodo įrankis, skirtas interneto puslapių kokybės auditui. Jis atlieka daugybę testų puslapyje ir sugeneruoja ataskaitą apie našumą, prieinamumą, geriausias praktikas ir SEO. Svarbiausia mūsų konvejeriui, jį galima paleisti programiškai ir sukonfigūruoti, kad būtų laikomasi našumo biudžetų.

Geriausias būdas integruoti „Lighthouse“ į CI/CD konvejerį yra naudojant Lighthouse CI. Tai įrankių rinkinys, kuris supaprastina „Lighthouse“ paleidimą, rezultatų patvirtinimą pagal biudžetus ir balų sekimą laikui bėgant.

Norėdami pradėti, turėtumėte sukurti konfigūracijos failą pavadinimu `lighthouserc.js` savo projekto šakniniame kataloge:

Pavyzdys: lighthouserc.js konfigūracija

• module.exports = {
• ci: {
• collect: {
• // 1 parinktis: paleisti su veikiančiu URL
• // url: ['https://staging.your-app.com'],
• // 2 parinktis: paleisti su lokaliai pateiktu „build“ išvesties aplanku
• staticDistDir: './build',
• startServerCommand: 'npm run start:static',
• },
• assert: {
• preset: 'lighthouse:recommended', // Pradėti nuo protingų numatytųjų nustatymų
• assertions: {
• // Individualūs teiginiai (jūsų našumo biudžetas)
• 'categories:performance': ['error', { minScore: 0.9 }], // Balas turi būti >= 90
• 'categories:accessibility': ['warn', { minScore: 0.95 }], // Balas turi būti >= 95
• 'core-web-vitals/largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
• 'core-web-vitals/total-blocking-time': ['error', { maxNumericValue: 200 }],
• },
• },
• upload: {
• target: 'temporary-public-storage', // Lengviausias būdas pradėti
• },
• },
• };

Su šia konfigūracija galite paleisti `lhci autorun` iš savo komandinės eilutės arba CI scenarijaus. Jis automatiškai paleis jūsų serverį, kelis kartus paleis „Lighthouse“ dėl stabilumo, patikrins rezultatus pagal jūsų teiginius ir atmes, jei biudžetas nebus įvykdytas.

Sintetinis stebėjimas ir tikrų vartotojų stebėjimas (RUM)

Svarbu suprasti skirtumą tarp dviejų pagrindinių našumo stebėjimo tipų.

• Sintetinis stebėjimas (laboratorijos duomenys): Tai yra tai, apie ką kalbėjome – automatizuotų testų vykdymas kontroliuojamoje, nuoseklioje aplinkoje („laboratorijoje“). Tai puikiai tinka CI/CD, nes izoliuoja jūsų kodo pakeitimų poveikį. Jūs kontroliuojate tinklo greitį, įrenginio tipą ir vietą. Jo stiprybė yra nuoseklumas ir regresijų aptikimas.
• Tikrų vartotojų stebėjimas (RUM) (realaus naudojimo duomenys): Tai apima našumo duomenų rinkimą iš realių jūsų vartotojų naršyklių visame pasaulyje („realiame naudojime“). RUM įrankiai (pvz., „Sentry“, „Datadog“ ar „New Relic“) naudoja mažą „JavaScript“ fragmentą jūsų svetainėje, kad praneštų apie pagrindinius interneto rodiklius ir kitus rodiklius, kaip juos patiria tikri žmonės. Jo stiprybė yra suteikti tikrą vaizdą apie pasaulinę vartotojų patirtį per nesuskaičiuojamą daugybę įrenginių ir tinklo derinių.

Šie du metodai vienas kito neatmeta; jie papildo vienas kitą. Naudokite sintetinį stebėjimą savo CI/CD konvejeryje, kad išvengtumėte regresijų diegimo. Naudokite RUM produkcinėje aplinkoje, kad suprastumėte savo realių vartotojų patirtį ir nustatytumėte tobulinimo sritis, kurių jūsų laboratoriniai testai gali praleisti.

Našumo profiliavimo integravimas į jūsų CI/CD konvejerį

Teorija yra puiku, bet svarbiausia yra praktinis įgyvendinimas. Sukurkime paprastą našumo patikrą naudojant „Lighthouse CI“ „GitHub Actions“ darbo eigoje.

Praktinis pavyzdys su „GitHub Actions“

Ši darbo eiga bus vykdoma su kiekvienu „pull request“. Ji sukompiliuoja programą, paleidžia „Lighthouse CI“ ir paskelbia rezultatus kaip komentarą prie „pull request“.

Sukurkite failą `.github/workflows/performance-ci.yml`:

Pavyzdys: .github/workflows/performance-ci.yml

• name: Performance CI
• on: [pull_request]
• jobs:
• lighthouse:
• runs-on: ubuntu-latest
• steps:
• - uses: actions/checkout@v3
• - name: Use Node.js 20.x
• uses: actions/setup-node@v3
• with:
• node-version: '20.x'
• cache: 'npm'
• - name: Install dependencies
• run: npm ci
• - name: Build production assets
• run: npm run build
• - name: Run Lighthouse CI
• run: |
• npm install -g @lhci/cli@0.12.x
• lhci autorun
• env:
• LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Kad tai veiktų, jums reikia dviejų dalykų:

1. `lighthouserc.js` failo jūsų repozitorijoje, kaip parodyta ankstesniame skyriuje.
2. „Lighthouse CI GitHub App“, įdiegtos jūsų repozitorijoje. Tai leidžia „Lighthouse CI“ skelbti komentarus ir būsenos patikras. Diegimo metu gausite prieigos raktą (`LHCI_GITHUB_APP_TOKEN`), kurį turite išsaugoti kaip paslaptį (secret) savo „GitHub“ repozitorijos nustatymuose.

Dabar, kai programuotojas atidaro „pull request“, atsiras būsenos patikra. Jei našumo biudžetas nebus įvykdytas, patikra bus raudona. Bus paskelbtas išsamus komentaras su „Lighthouse“ balais, tiksliai parodantis, kurie rodikliai pablogėjo.

Našumo duomenų saugojimas ir vizualizavimas

Nors `temporary-public-storage` puikiai tinka pradžiai, ilgalaikei analizei norėsite saugoti savo „Lighthouse“ ataskaitas. „Lighthouse CI Server“ yra nemokamas, atvirojo kodo sprendimas, kurį galite talpinti patys. Jis suteikia informacinį skydelį, skirtą vizualizuoti našumo tendencijas laikui bėgant, lyginti ataskaitas tarp šakų ir nustatyti laipsnišką našumo blogėjimą, kurio galima nepastebėti vieno paleidimo metu.

Konfigūruoti `lighthouserc.js`, kad duomenys būtų įkeliami į jūsų serverį, yra paprasta. Šie istoriniai duomenys paverčia jūsų konvejerį iš paprasto vartų sargo į galingą analizės įrankį.

Įspėjimai ir ataskaitos

Paskutinė dėlionės dalis yra efektyvi komunikacija. Nesėkmingas „build“ yra naudingas tik tada, kai tinkami žmonės yra laiku informuojami. Be „GitHub“ būsenos patikrų, apsvarstykite galimybę nustatyti įspėjimus savo komandos pagrindiniame komunikacijos kanale, pvz., „Slack“ ar „Microsoft Teams“. Geras įspėjimas turėtų apimti:

• Konkretų „pull request“ ar „commit“, kuris sukėlė nesėkmę.
• Kuris našumo rodiklis (ar rodikliai) pažeidė biudžetą ir kiek.
• Tiesioginę nuorodą į visą „Lighthouse“ ataskaitą gilesnei analizei.

Pažangios strategijos ir pasauliniai aspektai

Kai turėsite veikiantį pagrindinį konvejerį, galite jį patobulinti, kad geriau atspindėtų jūsų pasaulinę vartotojų bazę.

Įvairių tinklo ir procesoriaus sąlygų modeliavimas

Jūsų vartotojai ne visi naudojasi šviesolaidiniu internetu su galingais procesoriais. Svarbu testuoti realesnėmis sąlygomis. „Lighthouse“ turi integruotą lėtinimą (throttling), kuris pagal numatytuosius nustatymus imituoja lėtesnį tinklą ir procesorių (emuliuojant vidutinės klasės mobilųjį įrenginį 4G tinkle).

Galite pritaikyti šiuos nustatymus savo „Lighthouse“ konfigūracijoje, kad išbandytumėte įvairius scenarijus ir užtikrintumėte, jog jūsų programa išliks naudojama klientams rinkose su mažiau išvystyta interneto infrastruktūra.

Konkrečių vartotojo kelionių profiliavimas

Pradinis puslapio įkėlimas yra tik viena vartotojo patirties dalis. O kaip dėl prekės įdėjimo į krepšelį, paieškos filtro naudojimo ar formos pateikimo našumo? Galite sujungti „Playwright“ ir „Lighthouse“ galią, kad profiliuotumėte šias kritines sąveikas.

Įprastas modelis yra naudoti „Playwright“ scenarijų, kad naršytumėte programą iki tam tikros būsenos (pvz., prisijungti, įdėti prekes į krepšelį), o tada perduoti valdymą „Lighthouse“, kad jis atliktų auditą toje puslapio būsenoje. Tai suteikia daug holistiškesnį jūsų programos našumo vaizdą.

Išvada: našumo kultūros kūrimas

„JavaScript“ našumo stebėjimo automatizavimas yra ne tik apie įrankius ir scenarijus; tai apie kultūros, kurioje našumas yra bendra atsakomybė, puoselėjimą. Kai našumas traktuojamas kaip aukščiausios klasės savybė, išmatuojama ir nediskutuotina, jis tampa neatsiejama kūrimo proceso dalimi, o ne vėlesniu apmąstymu.

Pereidami nuo reaktyvaus, rankinio požiūrio prie proaktyvaus, automatizuoto konvejerio, jūs pasiekiate kelis svarbius verslo tikslus:

• Apsaugote vartotojo patirtį: Sukuriate saugumo tinklą, kuris neleidžia našumo regresijoms paveikti jūsų vartotojų.
• Padidinate kūrimo greitį: Teikdami neatidėliotiną grįžtamąjį ryšį, įgalinate programuotojus greitai ir užtikrintai spręsti problemas, sumažindami ilgus ir skausmingus optimizavimo ciklus.
• Priimate duomenimis pagrįstus sprendimus: Sukuriate turtingą našumo tendencijų duomenų rinkinį, kuris gali padėti priimti architektūrinius sprendimus ir pagrįsti investicijas į optimizavimą.

Kelionė prasideda nuo mažų žingsnelių. Pradėkite pridėdami paprastą „Lighthouse CI“ patikrą į savo pagrindinę šaką. Nustatykite konservatyvų našumo biudžetą. Kai jūsų komanda pripras prie grįžtamojo ryšio, išplėskite aprėptį į „pull requests“, įveskite detalesnius rodiklius ir pradėkite profiliuoti kritines vartotojų keliones. Našumas yra nuolatinė kelionė, o ne tikslas. Sukurdami proaktyvų konvejerį, užtikrinate, kad kiekviena jūsų išleista kodo eilutė gerbtų vertingiausią jūsų vartotojų turtą: jų laiką.